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A Data Processing Method, System and Computer Program 



15 Description 



Field of the invention 

The present invention relates in general to a data processing system and, in 
20 particular, to a supply chain management system and method- 
Background and prior art 

The modern logistic network of the business relationships has evolved into 
increasingly complex multi-partner and multi-system environment shaped by 
dynamic events. Supply chain management is getting more unpredictable for 

25 example due to outsourcing or globalization. The determination of a partner in 
the modern supply chain is usually done by functionalities located in vast array 
of systems: for example, planning systems, purchasing systems, and 
transportation systems. Many of these systems are often legacy systems. Thus, 
the coordination of processes inside the logistic network needs to be 

30 responsive, adaptive and open to integrate partners. 

U.S. Pat. No. 6,591,243 (Grettve et al.) discloses a method and system for 
improved supply chain management where detailed description of the prior art 
logistic systems and the related prior art problems are included. 

One of the considerable problems plaguing Supply Chain Management is the 
35 lack of timely communication between the different partners and systems in the 
supply chain what in turn results in higher costs, inadequate resources or even 

CONRRMATlOfi COPY 



WO 2005/022424 



PCT/EP2004/009348 



2 

5 waste. Also, the lack of possibility to quickly and effectively determine at run 
time which partners or systems are available adds to the problem. Therefore, 
there is a need for central data processing system that would be flexible and 
able to react to different business scenarios.. 

Summary of the invention 

10 According to various embodiments of the central data processing system 
disclosed herein, a method which integrates a plurality of functionalities for 
partner and system determination, as well as availability checking is described. 
The central data processing system includes hardware, software and 
communications components that cooperatively achieve the technical effect of 

15 an improved, centralized data processing in a supply chain management. A 
customer request containing plurality of items is received from a corresponding 
customer of a supply chain. Item unique identifiers are generated and assigned 
to the items. Then, a plurality of sub-requests is generated where each sub- 
request is assigned to a system by means of the rules. 

20 The sub-requests carrying separate unique identifiers are processed at the 
partner side and sub-responses are received at the central data processing 
system. Responses are generated based on association of sub-responses with 
the same original item and then, send back to the customer's data processing 
system. In case the synchronous communication is used the dynamic 

25. combining of the sub-results is performed at runtime. In case asynchronous 
communication is employed, the sub-responses are aggregated in a database 
until all sub-responses have been received. The amount of requested resources 
is adjusted in both cases based on the information received from the central 
data processing system. 

30 

The present invention makes possible to easily plug in the existing 
functionalities into the one central data processing system which could provide 
flexible and adaptable partner and system determination, as well as, availability 
checks in a supply chain management It also enables faster and more effective 
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5 execution and control of logistic processes in a complex partner/system 
environment. It also provides an interface that allows a customer to deal with 
one system and avoid the complexity of multiple systems and functions. 

In another aspect, the present invention relates to a data processing system for 

10 processing a request. Typically, the request comprises a number of request 
items. For example,- the request can be a costumer query regarding the 
availability and delivery conditions for the items as listed in the request. The 
data processing system is coupled to a number of partner computer systems. 
The data processing system selects an asynchronous or a synchronous 

15 communication mode for communication with the partner computer systems in 
order to process the request. The determination whether asynchronous or 
synchronous communication is to be selected can be made using a set of rules 
that are applied on the request. This rulebase can also be used in order to split 
the request into a set of sub-requests where each sub-request is assigned to 

20 one of the partner computer systems. If the synchronous communication mode 
has been selected with respect to one of the partner computer systems the sub- 
requests are sent sequentially from the data processing system to the 
respective partner computer systems. In other words, a consecutive sub- 
request is only sent from the data processing system to one of the partner 

25 computer systems if a response to a previous sub-request has been received 
by the data processing system. The sub-responses of the partner computer 
systems are held in the main memory of the data processing system, i.e. a 
random access memory. After all sub-responses have been received, the sub- 
responses are combined into a consolidated response that is sent back to the 

30 requestor, e.g. the sales system. 

If the asynchronous communication mode has been selected some or all of the 
sub-requests can be sent in parallel to the respective partner computer 
systems. Each time a sub-response is received from the partner computer 
35 systems, the status of a database is checked. The database is stored on a non- 
volatile storage device, such as a magnetic disc. If the status of the database 
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5 indicates that all sub-responses except the newly received sub-response are 
already present in the database, the sub-responses are read out from the 
database and are combined into a consolidated response which is then sent 
back to the requestor. 

10 For example, a unique identifier, such as a globally unique identifier (GUID), is 
assigned to the sub-requests. The sub-request that is sent to a partner 
computer system carries its unique identifier. The sub-response received from 
the partner computer system in response to the respective sub-request carries 
the same unique identifier. The unique identifiers are used as database keys for 

15 storing the sub-responses in the database and for determining the status of the 
database by querying the database by means of the unique identifiers. 

The present invention is particularly advantageous as it enables the data 
processing system to communicate both in an asynchronous or a synchronous 

20 communication mode with the partner computer systems that are coupled to the 
central data processing system. The synchronous communication mode has the 
advantage that a response can be provided to the requestor with a minimal 
latency time, as no storage operations on the non-volatile storage device and 
no database queries are required as the respective information is held in the 

25 random access memory. However, the synchronous communication mode does 
not allow to send a number of the sub-requests in parallel to the partner 
computer systems. As parallelization of the processing is not possible this 
results in relatively long idle times for the data processing system where the 
data processing system is In a wait state in order to wait for a sub-response 

30 until the next sub-request can be sent out to the respective partner computer 
system. 

The asynchronous communication mode has the advantage that a number of 
sub-requests can be sent out in parallel to the partner computer systems. 
35 Because of the storage of the sub-responses in the database and the query 
operations that are required in order to determine whether all sub-responses 
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5 have already been received a longer latency time is typically experienced in the 
asynchronous communication mode for providing the response. However, the 
parallelization of the processing substantially reduces the idle times of the 
central data processing system and thus enables to maximize the overall 
system throughput in order to make maximum usage of the available hardware 
10 resources. 

It is thus possible to select the synchronous or asynchronous communication 
modes depending on the requestor's preferences which can be given in the 
request and / or depending on the partner computer system's communication 

15 capabilities. For example, some of the partner computer systems are capable to 
communicate in only one of the asynchronous or synchronous communication 
modes whereas other partner computer systems have the capability to 
communicate both in the asynchronous and synchronous communication 
modes. These capabilities of the partner computer systems and / or user 

20 preferences can be stored as rules in the central data processing system for 
selecting the asynchronous or synchronous communication modes. 

In particular the present invention can be used for a fulfilment coordination 
engine as described in PCT Patent Application WO 03/075195 A2 which is 
25 herein incorporated by reference in its entirety. 

Brief description of the drawings 

* 

Figure 1 illustrates a central data processing system for processing of the 
30 customer request of the present invention. 

Figure 2 is a flowchart of a process describing a method of the present 
invention. 



35 



Figure 3A 



illustrates structure of the document used in a central data 
processing system and mapping of the data from standard orders. 



WO 2005/022424 PCT/EP2004/009348 



5 

Figure 3B illustrates the case when base documents used in a central data 
processing system create document hierarchies. 

Figure 4 is a block diagram of a more detailed embodiment of the central 
10 data processing system of the present invention where 

synchronous communication is used. 

Figure 5 is a block diagram of a more detailed embodiment of the central 
data processing system of the present invention where 
15 asynchronous communication is used. 

Figure 6 is a block diagram of a further preferred embodiment of a data 
processing system of the invention, 

20 Figure 7 is a flow diagram illustrating a preferred mode of operation of the 
data processing system of figure 6. 

Detailed description 

The claimed invention is applicable to many different industries. One skilled in 
25 the art will appreciate that the various embodiments and concepts of the 
present invention are applicable to plurality of industries without straying from 
the spirit of the present invention. 

The present invention includes a supply chain management system involving at 
30 least one customer. Supply chain also includes at least one partner. The supply 
chain partners include business partners, locations and logical systems. 



35 



Exchange Infrastructure (XI) can be used for various embodiments of the 
present invention. It enables the development of the cross-system applications 
that exchange a multitude of system messages using the runtime infrastructure 
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5 and synchronous or asynchronous communication. However, since the use of 
synchronous communication via the XI currently requires that the called function 
works without state, the partner ascertainment service can only be called 
synchronously via the XI if the application scenario does not require that the 
partner ascertainment service or any of the partner ascertainment functions it 

10 calls work with state. 

The aim of the Exchange Infrastructure is to integrate different systems 
implemented on different platforms (Java, ABAP, and so on). The Exchange 
Infrastructure is based on an open architecture, makes uses of open standards, 

15 in particular those from the XML (extensible Markup Language) and Java 
environments; and offers services that are essential in a heterogeneous and 
complex system landscape: namely a runtime infrastructure for message 
exchange; configuration options for managing business processes and 
message flow; and options for transforming message contents between the 

20 sender and receiver systems. 

Figure 1 illustrates a central data processing system 108 for processing of a 
customer request 114 according to an embodiment of the present invention. 
Sales system 104 provides electronic connectivity to the central data processing 
25 system and enables collection of customer requests for future processing. 
Utilizing a network, for example an Internet 102, a request for at least one item 
is received from a corresponding customer 100 at the central data processing 
system. 

30 Subsequently, a central data processing system checks if each item has a 
unique identifier 106; if an item is found without a unique identifier, a new 
unique identifier 116 is generated and assigned to this item. Customer requests 
comprising a plurality of items are then processed by means of a set of rules 
1 18 in a looping mode, that is when the request has more then one item then 

35 each item is sequentially processed and the response is send for each item. 
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5 The control program 110 implements the corresponding control processes. The 
assigned unique identifiers are then stored in a database 1 12. When partner 
systems such as for example a purchasing system 120, a manufacturing 
system 122, a planning system 124 or any other internal or external 
systems126 send their responses back, those responses are associated in turn 

10 with the original items and the final response is then sent to the customer's data 
processing system. > 

Figure 2 depicts a corresponding flow chart. In the step 200 a request for at 
least one item is sent by the customer's data processing system, in this case a 

15 Sales system. When request is received in a central data processing system, in 
this case a Fulfilment Coordination Engine (FCE), in the step 202 each item is 
checked for presence of the unique identifier; if the unique identifier is missing 
the FCE generates and assigns unique identifiers to the item. Then, in the step 
204, the sub-requests are generated and assigned to a partner's system by 

20 means of the rules. 

In the next step 206 each of the sub-requests receives a separate unique 
identifier and assigned unique identifiers are stored in the retrievable medium in 
the step 208. That means that in case of asynchronous communication, the 
25 unique identifiers are stored in the database. However, in the case of 

synchronous communication the unique identifiers are stored in the memory 
and they are only in this case stored in the database when the Logical Unit of 
Work (LUW) in the called system is ended with the command COMMIT. In the 
step 210 sub-requests are sent to partner systems. 

30 

At the partner system side steps 212 and 214 are performed. First, all the 
requests are processed and then sub-responses including unique identifiers 
and information are send back to the central data processing system. Fulfilment 
Coordination Engine, in the step 216, receives all sub-responses from the 
35 partner systems and in the step 218, the responses are generated based on 
association of sub-responses with the original item. In the final step 220, the 
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5 responses are send back to the customer's data processing system, in this case 
a sales system. 

Figure 3A illustrates a structure of the document used in the central data 
processing system and associated mapping of the data from standard orders. 
10 Data processing conducted in multi-system and multi-business environment 
means that various document types can be used such as for example purchase 
orders or sales orders. 

In order to be able to operate on the plurality of documents, central data 
15 processing system can for example use an order-like document structure 326 
that consists of a header section 328, at least one item 330 that can contain for 
example fields like business partner, product, location or contract; and at least 
one schedule line 332 per item comprising information regarding a delivery date 
and a quantity. This special design of the three level structure allows all 
20 documents that exist in internal systems as well as all those documents of 

different applications that are relevant for central data processing to be mapped. 
If for example, sales order processing calls the central data processing system, 
then the data of the sales order 334 that was transferred to the central data 
processing system via the interface, is mapped onto the document 326. 

25 

The sales order header 335 is mapped on the document header 328, the order 
items 336 are mapped on the document items 330 and the request schedule 
lines 337 on the document schedule lines 332. The similar process takes place 
when the system receives a purchase order 344. The purchase order header 
30 345 is mapped on the document header 328, the purchase order items 346 are 
mapped on the document items 330 and the purchase order schedule lines 347 
on the document schedule lines 332. 



35 



Figure 3B depicts, for example, the case when product substitution and/or 
location substitution occurs and base documents 350 create document 
hierarchies. For example in the result 358, schedule lines 354 have a list of 
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5 successor items 352 which can include partners, substitution products or 

locations. Also, a schedule line 354 contains several successor documents 356. 
Beside product and/or location substitution also further hierarchy levels can be 
produced in the document. 

10 Figure 4 illustrates a more detailed embodiment of the data processing system 
of the present invention, describing a case when synchronous communication is 
used throughout the supply chain. The embodiment of Figure 4 constitutes a 
logical continuation of the Figure 1 where like elements are referenced by like 
reference numbers having added 300. Synchronous communication takes place 

15 in this embodiment of the invention via Synchronous Remote Function Call 
(sRFC) 413 if any of the called partner functions work with state. Since the use 
of synchronous communication via the XI currently requires that the called 
function works without state, the partner ascertainment service can only be 
called synchronously via the XI if the application scenario does not require that 

20 the partner ascertainment service or any of the partner's functions it calls work 
with state. 

According with the preferred embodiment the central data processing system is 
in this case a Fulfilment Coordination Engine (FCE) 408. As shown in Figure 4, 

25 FCE receives a request 414 for at least one item from a corresponding 

customer 400 via the Network 409 which can also include Internet 402. In this 
case a calling application is a Sales system 404. Subsequently, each item is 
checked for the presence of a unique identifier 406, if an item is found without a 
unique identifier, a new unique identifier 416 is generated and assigned to this 

30 item. The control program 410 is the central component of the Fulfilment 
Coordination Engine. 

The control program must be called to begin the request processing. The set of 
rules 418 determined by the control program contains a sort profile, a selection 
35 profile, a search key and the determination procedure. A sort profile is used to 
determine how partner lists should be sorted for further processing. A selection 
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5 profile is used to define the procedure used to select partners. A search key and 
the determination procedure are used to determine whether an availability 
check is executed and if so, what kind. A plurality of sub-requests 430 for 
plurality of partners' systems is then generated where each sub-request is 
assigned to an internal or external system by means of the set of rules where 

10 complex dependencies have access using Condition Technology 427. In this 
case, the objects, for example rules searched for are determined by evaluating 
conditions. The search key is then interpreted as a condition type. 

The Fulfilment Coordination Engine then calls synchronously functions 417 
15 according to Customizing 425. When synchronous communication is used, the 
customer receives immediately a response also synchronously, so that 
customer's data processing system can continue working. In most cases, called 
functions are implemented in the external systems. Functions are not called 
directly but via corresponding interfaces 415. In contrast to functions, the 
20 interfaces are always implemented on the side of the central data processing 
system. The call of a function, and the respective mapping are implemented 
within an interface. There is a 1:1 relationship between interfaces and functions; 
There must be a separate interface for each of the functions. In contrast, an N: 
M relationship exists between interfaces and logical systems. 

25 

The assigned unique identifiers are then stored in a database 412 while sub- 
requests are sent to different partner systems. Sending of the sub-requests to 
partner systems such as for example a purchasing system 420, a 
manufacturing system 422, a planning system 424 or any other internal or 

30 external systems 426 further comprises either sending a request for a partner 
search or a partner availability check at schedule-line level or determining at 
least one business system or an availability check for this system at schedule- 
line level. It is further determined on the item level which availability check 
function should be called. A separate unique identifier for each of the sub- 

35 requests Is then generated. 



WO 2005/022424 PCT7EP2004/009348 

12 

5 Availability check returns confirmation of dates and quantities as well as, if 
necessary, alternative products and/or locations are included. The availability 
check reserves temporary a requested resources that have been identified as 
available. The resources are reserved this way that the requested resources are 
equal to the original resources less the quantities that have already been 

10 confirmed and reserved via partner's system functions previously called. Thus, 
availability checks carried out In processes running in parallel do not consume 
the same quantities. It is assured that overbooking of resources does not occur 
during an availability check. 

15 Some functions enable the assignment of an expiration date to their temporary 
quantity assignments. If this date has been reached, the temporary quantity 
assignments are automatically handled (deleted, for example). Up to this date, 
the temporary quantity assignments are active, that is, they reserve a quantity. 
However, if the expiration date is not assigned automatically, the Fulfilment 

20 Coordination Engine has to sent a specific message terminating the reservation 
of resources. 

On the other hand, when partner search is executed, a list of partners is 
returned. Subject to the partner's functions used, further data such as prices 
25 and contracts, and similar, can be also included. 

Supply Chain Management (SCM) scheduling module 428 can be called by the 
Fulfilment Coordination Engine to determine the dates which are transferred to 
the partners' functions based on the dates received from the customer. Also, it 
30 is further used to determine the dates to be returned to the customer based on 
the dates received in the sub-responses from the partners' systems. 

When Fulfilment Coordination Engine receives the sub-responses 432, those 
resulting sub-responses which are sent by the partner systems back to the FCE 
35 have the same unique identifiers as the sub-requests sent originally. Thus, the 
sub-responses can be associated on the base of the matched unique identifiers 
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5 with the original sub-requests. Those sub-responses are then stored in the 
main memory 411 of the Fulfilment Coordination Engine and the internal logic 
checks if all the roots of the unique identifiers are there so the final response 
434 can be sent to the customer's data processing system immediately in order 
for it to continue working without interruptions. The response can be displayed 
10 utilizing a sales system interface 407. However, it is also possible that the result 
is not displayed at all, it depends on the calling system/application which of the 
two options occurs. In any case, all the details of the partner search or/and 
availability check are hidden from the calling system/application. 

15 Figure 5 illustrates a more detailed embodiment of the data processing system 
of the present invention, describing a case when an asynchronous 
communication is used throughout the supply chain. The embodiment of Figure 
5 constitutes a logical continuation of the Figure 1 where like elements are 
referenced by like reference numbers having added 400. 

20 

According with the preferred embodiment the central data processing system is 
in this case a Fulfilment Coordination Engine (FCE) 508. In the case of the use 
of asynchronous communication the Fulfilment Coordination Engine is called 
asynchronously and it also calls asynchronously the functions located in the 
25 external partner systems (520, 522, 524, and 526) via the control program. 
Asynchronous communication takes place via the Exchange Infrastructure (XI) 
513. 

Thus, the Fulfilment Coordination Engine 508 receives asynchronously a 
30 request 514 for at least one item from a corresponding customer 500 via the 
Network 509. In this case an asynchronous call is made by sales system 504. 
Subsequently, each item is checked for the presence of a unique identifier 506, 
if an item is found without a unique identifier, a new unique identifier 516 is 
generated and assigned to this item. A plurality of sub-requests 530 for plurality 
35 of partners' systems is then generated where each sub-request is assigned to 
an internal or external system by means of the set of rules 518 which allow to 
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5 configure the sequence functions are called. Complex dependencies have 
access using Condition Technology 527. Then the Fulfilment Coordination 
Engine calls asynchronously partner's functions according to Customizing 525 
via the control program 510 and the sub-requests are processed at the partner 
side. The resulting sub-responses which are sent by the partner systems back 

10 to the Fulfilment Coordination Engine have the same unique identifiers as the 
sub-requests sent originally. 

Thus, when FCE receives asynchronously the sub-responses 532, those sub- 
responses are stored in the database tables 51 1 and can be associated on the 

15 base of the matched unique identifiers with the original sub-requests, so that the 
central data processing can be continued when all the sub-responses of the 
asynchronous function calls are available. In order to determine if all sub- 
responses are collected, a control program 510 performs a query each time a 
sub-response comes back from the partner system, in order to retrieve all 

20 relevant sub-responses stored so far in the database. 

If the number of the stored responses is determined to be insufficient, the 
received sub-response is then stored in the database until all the sub-responses 
are collected. When on the other hand, the database query determines all the 

25 received sub-responses to be sufficient, then the final response 534 is sent to 
the customer's data processing system. The response can be displayed utilizing 
a sales system interface 507. However, it is also possible that the result is not 
displayed at all, it depends on the calling system/application which of the two 
options occurs. In any case, all the details of the partner search or/and 

30 availability check are hidden from the calling system/application. 

SCM scheduling module 528 can be called by the Fulfilment Coordination 
Engine system to determine the dates which are transferred to the partners 1 
functions based on the dates received from the customer. Also, it is further used 
35 to determine the dates to be returned to the customer based on the dates 
received in the sub-responses from the partners' systems. 
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5 

In case of asynchronous communication, also the workflow 529 can be used 
together with the Fulfilment Coordination Engine. In this case sub-responses 
from partner's functions are received via the workflow which is started when 
asynchronous calls of the partner's functions are triggered. 

10 

Figure 6 shows a block diagram of an alternative embodiment of the central 
data processing system. Elements of the embodiment of figure 6 that 
correspond to elements of the embodiments of figures 1 , 4 or 5 are designated 
by like reference numerals. 

15 

The central data processing system 608 has a control program 610 that is 
executed by a processor of the central data processing system 608 (not shown 
In the drawing). The control program 610 controls operation of the central data 
processing system 608. Further, the central data processing system 608 has a 

20 rules module 618 for storage of rules that are used for selecting the 

asynchronous or synchronous communication mode and for splitting a request 
614 into sub-requests 630. The central data processing system 608 has one or 
more interfaces 619, such as TCP/ IP capable interfaces, for receiving the 
customer request 614, sending a response to the customer request back to the 

25 requestor and for communicating with the partner computer systems (not shown 
in figure 6) that are coupled to the central data processing system 608. 

The central data processing system 608 has a non-volatile storage medium, 
such as a magnetic disc, for storing a database 612. In addition the central data 

30 processing system 608 has a main memory 613, i.e. a random access memory. 
Depending on the selected communication mode sub-responses received from 
the partner computer systems are stored in the database 612 or in the main 
memory 613. After all sub-responses for a request 614 have been received a 
respective response that combines the sub-responses is generated and sent 

35 back to the requestor from the central data processing system 608. 
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5 In operation the central data processing system 608 receives the request 614. 
In the example considered here, the request 614 carries a number of items A, 
B t C... that identify respective products or services that the customer considers 
to purchase or order. When the central data processing system 608 receives 
the request 614 the control program 610 is invoked and applies the rules of 

10 rules module 61 8 to the customer request in order to select the synchronous or 
asynchronous communication mode and in order to split the request 614 into 
sub-requests, if necessary. In addition, individual items contained in the request 
614 can be split into sub-items, if required by the rules. Each item, sub-item and 
sub-request get assigned a unique identifier (ID) such as a globally unique 

15 identifier. 

If the synchronous communication mode is selected, data 670 Is stored in the 
main memory 613. The data 670 describes the mapping of item IDs to sub-item 
IDs. Likewise data 672 that describes the mapping of sub-requests to item and 
20 sub-item IDs is stored in the main memory 613. 

When one of the sub-requests 630 is sent from the central data processing 
system 608 to the respective partner computer system, the central data 
processing system 608 receives a sub-response 632. Both the sub-request 630 
25 and the sub-response 632 carry the same sub-request ID that enables the 

central data processing system 608 to interpret sub-response 632 as belonging 
to the sub-request 630. In the synchronous communication mode the sub- 
responses 632 that are received from the partner computer systems are stored 
in the main memory 613. 

30 

In the asynchronous communication mode the data 670 and data 672 is stored 
on a non-volatile storage medium. The sub-responses 632 are stored in the 
database 612 using the respecting sub-request IDs as database keys. 

35 In the synchronous communication mode the central data processing system 
608 sends one of the sub-requests 630 of request 614 at a time to the 
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5 respective partner computer system. The central data processing system 608 
waits for the sub-response 632 until the next sub-request 630 is sent out. When 
all sub-responses 632 have been received and temporarily stored in the main 
memory 613 the sub-responses 632 are combined by the control program 610 
in order generate a response that is sent back to the requestor by means of 

10 interface 619. 

In the asynchronous communication mode a plurality of the sub-requests 630 
can be sent out to the respective partner computer systems in parallel. Each 
time a sub-response 632 is received from one of the partner computer systems 

15 the status of the database 612 is checked for completeness of the sub- 
responses 632. This can be done by querying the database 612 using the sub- 
request IDs of the sub-responses as a query criterion. If all sub-responses 632 
for a given request 614 except the newly received sub-response 632 are 
already stored in the database 612 the sub-responses 632 are read from the 

20 database 612 into the main memory 61 3 for generating the response to the 
requestor. 

Figure 7 shows a corresponding flowchart. 

25 In step 700 a customer request is received by the central data processing 

system. In step 702 a set of rules is applied to the request in order to determine 
whether synchronous or asynchronous communication is to be used. In addition 
the request is split up into a number J of sub-requests j if required (step 704 in 
the case of synchronous communication and step 706 in the step of 

30 asynchronous communication). 

In the synchronous communication mode the index j is initialized in step 708. In 
step 710 the first sub-request j is sent from the central data processing system 
to the respective partner computer system. The central data processing system 
35 is in a wait state until it receives the sub-response j from the partner computer 
system in step 712. The sub-response j is stored in the random access memory 
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5 of the central data processing system. In step 714 the index j is incremented 
and the control goes back to step 710. 

After all sub-responses j for the request have been received the control goes to 
step 716 where the sub-responses that are temporarily stored in the random 
10 access memory are combined in order to generate the response to the request 
received in step 700 ( step 716). The response is sent back to the requestor in 
step 718. 

If the asynchronous communication mode has been selected in step 702 the 
15 unique identifiers that are assigned to the sub-requests are used as keys for 
storage of the sub-requests In the database (step 706). In step 720 the sub- 
requests are sent to the partner computer systems. This can be done in parallel. 
In step 722 a sub-response is received from one of the partner computer 
systems. The sub-response carries the same unique ID as its respective sub- 
20 request. This enables the central data processing system to identify the sub- 
response as belonging to one of the sub-requests that have been sent but in 
step 720. In step 724 the central data processing system checks the status of 
the database. If all sub-responses have already been received the previously 
received sub-responses are read from the database in step 726 and the 
25 response is generated in step 728 before it is sent out in step 718. 

If the contrary is the case, the sub-response received in step 722 is stored in 
the database using its unique ID as a key (step 730). From there the control 
goes back to step 722. The status check in step 724 is performed each time a 
30 sub-response is received from one of the partner computer systems in order to 
determine, whether all sub-responses have already been received or not. 

Although the present invention has been described in detail with reference to 
certain preferred versions thereof, other versions are possible. The detailed 
35 descriptions of the synchronous and asynchronous communication in figures 4 
and 5 were presented as unmixed systems for the sake of the clarity. 
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Nevertheless, the present invention is also designed for the many versions of 
mixed asynchronous and synchronous communication. For example, the calling 
system/application can send a synchronous call, then the Fulfilment 
Coordination Engine can call some of the partner systems using synchronous 
communication and other systems can be called asynchronously. Also, other 
variations of mixed systems are possible. Therefore the spirit and scope of the 
appended claims should not be limited to the preferred versions herein. 
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5 

List of Reference Numerals 



100 customer 

102 internet 

104 sales system 

106 unique identifier 

1 08 central data processing system 

110 control program 

112 database 

114 request 

116 unique identifier 

118 rules module 

1 20 purchasing system 

122 manufacturing system 

124 planning system 

126 other internal or external system 

326 document of the central data processing 
system 

328 document header 

330 document items 

332 document schedule lines 

334 sales order 

335 sales order header 

336 sales order items 

337 sales order schedule lines 

344 purchase order 

345 purchase order header 

346 purchase order items 

347 purchase order schedule lines 
350 base document 
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352 item 

354 schedule line 

356 successor document 

358 result 

400 customer 

402 internet 

404 sales system 

406 unique Identifier 

407 interface 

408 Fulfilment Coordination Engine 

409 network 

410 control program 

41 1 memory used for storage of sub- 
responses 

412 database used for storage of the unique 
identifiers 

413 Synchronous Remote Function Call 

414 request 

415 interface 

416 unique identifier 

417 functions 

418 rules module 

420 purchasing system 

422 manufacturing system 

424 planning system 

425 customizing and core data module 

426 other internal or external system 

427 Condition Technology module 

428 scheduling module 

429 workflow module 

430 sub-request 
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432 
434 
500 
502 
504 
506 
507 
508 
509 
510 
511 

512 

513 
514 
515 
516 
517 
518 
520 
522 
524 
525 
526 
527 
528 
529 
530 
532 
534 
608 



sub-response 

response 

customer 

internet 

sales system 

unique Identifier 

interface 

Fulfilment Coordination Engine 

network 

control program 

database used for storage of sub- 
responses 

database used for storage of the unique 
identifiers 

XI Routing 

request 

interface 

unique identifier 

functions 

rules module 

purchasing system 

manufacturing system 

planning system 

customizing and core data module 

other internal or external system 

Condition Technology module 

scheduling module 

workflow module 

sub-request 

sub-response 

response 

central data processing system 
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610 control program 

612 database 

613 main memory 

614 request 

618 rules module 

619 interface 
670 data 
672 data 
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CLAIMS 



1 . A data processing method for a customer request comprising the steps of: 

a) receiving a request for at least one item at a central data processing 
system; 

b) generating a plurality of sub-requests for a plurality of partner systems 
where each sub-request is assigned to an internal or external system 
by means of rules; 

c) generating a separate unique identifier for each of the sub-requests; 

d) storing the unique identifiers being assigned to the sub-requests, in a 
retrievable medium; 

e) sending the sub-requests with the unique identifiers to partner 
systems; 

f) receiving back sub-responses at the central data processing system, 
said sub-responses having unique identifiers in association with the 
unique Identifiers of the request; 

g) generating a response based on association of the sub-responses with 
the original item; 

h) sending the response back to the customer data processing system. 

2. The method of claim 1 , wherein said sending of the sub-requests to 
partner systems further comprises at least one of the following steps: 

- sending a sub-request for a partner search or a partner availability check 
at item level or: 

- determining at least one business system or an availability check for this 
system at item level. 

3. The method of claim 2, wherein performing of the partner search is done 
with the use of functions. 

4. The method of claim 3, wherein the functions comprise standard functions, 
as well as functions of customers and partners. 
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5. The method of claim 2, whereby the partner system which received the 
request for availability check temporarily reserves a requested resource 
that has been identified as available. 

10 6. The method of claim 5, whereby the partner system deletes the 

reservation for the requested resources unless the central data processing 
system sends a message if no acceptance is received from the customer 
within the predetermined time interval. 

15 7. The method of any one of the preceding claims, wherein the request 

comprises a plurality of items and steps b) to g) are carried out for each 
item. 

8. The method of any one of the preceding claims, whereby the request 
20 comprising a plurality of items is processed in a looping mode. 

9. The method of any one of the preceding claims, wherein the request for 
the at least one item has a structure of an order-like document that 
comprises: 

25 - a header section; 

- at least one item; 

- at least one schedule line per item comprising information regarding 
requested by the customer a delivery date and a quantity. 

30 10. The method of any one of the preceding claims, wherein the step b) 
includes criteria defined by the customer. 

1 1 . The method of any one of the preceding claims, further comprising the 
following steps conducted prior to step h): 

35 
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5 - comparing at least one sub-response to the preferred choice 

specified by a customer; 
- selecting a preferred choice from the group consisting of the at 
least one sub-response. 

10 12. The method of claim 1 1 , wherein the act of selecting the preferred choice 
is based on customer's preferences. 

13. The method of claim 1 1 or 12, wherein asynchronous communication 
means are used and the sub-responses are aggregated in the database 

15 until all sub-responses have been received. 

14. A central data processing system for processing of the customer request 
comprising: 

a) means for receiving the request (1 14; 414; 514) for at least one 
20 item at a central data processing system (1 08); 

b) means for generating a plurality of sub-requests (430,530) for 
plurality of partners where each sub-request is assigned to an 
internal or external system by means of the rules (118; 418; 518); 

c) means for generating a separate unique identifier (1 16;416;516) 
25 for each of the sub-requests; 

d) means for storing the unique identifiers being assigned to the sub- 
requests, in a retrievable medium (112; 412; 512); 

e) means for sending the sub-requests with the unique identifiers to 
partner systems; 

30 f) means for receiving back sub-responses (432; 532) at the central 

data processing system, said sub-responses having unique 
identifiers in association with the unique identifiers of the request; 
g) means for generating a response (434; 534) based on association 
of the sub-responses with the original item; 

35 h) means for sending the response back to the customer data 

processing system. 
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15. The central data processing system of claim 14, whereby a central data 
processing system further comprises interfaces for communication 
between a sales system, the purchasing system, the manufacturing 
system, the planning system and other internal or external systems. 

10 

16. The system of claim 14 or 15, further comprising asynchronous 
communication means being adapted to the use of database tables for 
storage of the sub-responses. 

15 17. The system of claim 16, wherein the means of generating a response 
based on association of the sub-responses with the original item and 
sending the response back to the customer data processing system, in 
case of the asynchronous communication, are applied only when all the 
requested sub-responses are collected in the database. 

20 

18. The system of claim 17, wherein the asynchronous communication means 
are adapted to execute a query to determine if all necessary sub- 
responses have been collected. 

A computer-readable storage medium holding code for performing the 
steps of: 

a) receiving a request for at least one item at a central data 
processing system; 

b) generating a plurality of sub-requests for plurality of partners 
where each sub-request is assigned to an internal or external 
system by means of rules; 

c) generating a separate unique identifier for each of the sub- 
requests; 

d) storing the unique identifiers being assigned to the sub-requests, 
in a retrievable medium; 
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5 e) sending the sub-requests with the unique identifiers to partner 

systems; 

f) receiving back sub-responses at the central data processing 
system, said sub-responses having unique identifiers in 
association with the unique identifiers of the request; 
10 g) generating a response based on association of the sub-responses 

with the original item; 
h) sending the response back to the customer data processing 
system. 

15 20. A data processing system for processing a request (614), the data 
processing system comprising: 

- means (61 0, 61 8) for selecting an asynchronous or a 
synchronous communication mode for communication with 

20 partner computer systems, 

- means for splitting the request into a set of sub-requests (630), 

- synchronous communication means (610, 613) being adapted to 
send a first one of the sub-requests of the set of sub-requests to 
one of the partner computer systems, wait for the respective sub- 

25 response from the one of the partner computer systems and 

send a second one of the sub-requests of the set of sub-requests 
to one of the partner computer systems after the sub-response 
has been received, wherein the sub-responses are stored in a 
random access memory (613), 

30 - asynchronous communication means (610, 61 2) being adapted 

to send the sub-requests in parallel to the partner computer 
systems, store respective sub-responses of the partner computer 
systems in a database (612) on a non-volatile storage device, 

- means (61 0) for combining the sub-responses to generate a 
35 response to the request, 

- means (610, 619) for sending the response. 
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21 . The data processing system of claim 20, wherein the means for selecting 
the asynchronous or synchronous communication mode comprises a set 
of rules (6189 to be applied on the request. 

10 22. The data processing system of claim 21 , wherein the means for splitting 
the request into a set of sub-requests uses the set of rules for the splitting 
operation. 

23. The data processing system of claims 20, 21 or 22, the asynchronous 
15 communication means being adapted to check the database for 

completeness for each incoming sub-response. 

24. The data processing system of claim 23, the asynchronous communication 
means being adapted to perform the check of the database by performing 

20 a database query using the sub-request and sub-response identifiers as 

keys. 

25. A method for processing a request comprising: 

25 - selecting an asynchronous or synchronous communication mode 

for communication with partner computer systems, 

- splitting the request into a set of sub-requests, 

- if the synchronous communication mode has been selected: 
sending a first one of the sub-requests of the set to one of the 

30 partner computer systems, waiting for the respective sub- 

response from the one of the partner computer systems, sending 
a second one of the sub-requests of the set to a second one of 
the partner computer systems after the sub-response from the 
first one of the partner computer systems has been received, 

35 wherein the sub-responses are stored in a random access 

memory, 
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- if the asynchronous communication mode has been selected: 
sending a plurality of the sub-requests in parallel to partner 
computer systems, storing respective sub-responses of the 
partner computer systems in a database on a non-volatile 
storage device, 

- combining the sub-responses to generate a response to the 
request, 

- sending the response to the requestor. 

26. The data processing method of claim 25, wherein a set of rules is used for 
selecting the asynchronous or the synchronous communication mode and 
for splitting the request into a set of sub-requests. 

27. The data processing methods of claim 25 or 26, further comprising 
checking the asynchronous communication mode, checking the database 
for completeness with each incoming sub-response. 

28. The data processing method of claim 27, wherein a database query is 
performed for each incoming sub-response, in order to determine whether 
ail sub-responses for the request have been received. 

29. A computer program product comprising computer executable instructions 
for performing a method in accordance with anyone of the preceding 
claims 25 to 28. 



WO 2005/022424 



1/8 



PCT/EP2004/009348 





SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PCT/EP2004/009348 



2/8 



Sales 
System 



Fulfillment 
Coordination 
Engine 



Partner 
Systems 



Fulfillment 
Coordination 
Engine 



FIG. 2 




No 


generate Unique 


> ► 


identifier 



Yes 




Generate sub 


-requests and 


determine a potential partner 



I 



Assign unique Identifiers to sub- 
requests 



Store assigned Unique Identifiers 
in a retrievable medium 



Send sub-requests to partner 
systems 



Process the sub-requests 



Sending back sub-responses 
(Unique identifiers and Information) 



Receive all sub-responses 
(Unique Identifiers and Information) 



Generate responses 



Send responses back to 
the customer 



204 



206 



208 



210 



212 



214 



216 



218 



220 



202 



SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PC17EP2004/009348 




SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PCT/EP2004/009348 



4/8 



350 



352 



Base Document 



Item 



1 t* 



«inherits» 



1 * 



Successor Document 



0..* 1 



Line 



1 1. 



Result 



T 

356 



T 

354 



T 

358 



FIG. 3B 



SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PCT/EP2004/009348 



5/8 






E 








I 




CO 


c 




nctio 


turinc 




o 


LL. 


ra 








C 


) 


Ma 



§ £ a 

* Tt ^ 



SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 PCT/EP2004/009348 



6/8 




CM 

m 




m 
CD 



N CO O) 
CM CM CM 

m m m 



isanbai 


asuodsej 




•qns 


■qns 


10 



10 



doejje)U| 




Unique 
identifier 


Sales \ 
System 






SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PCT/EP2004/009348 



7/8 



Customer Request 
-item A 
•itemB 
•itemC 



614 



1 



608 



Central Data Processing Sytem 



Control Program 



i 



610 
612 



Rules Module 



Database 



item ID -*• sub-item ID 



1 



670 
672 



sub-request ID ->(item ID; sub-item ID) 



sup-responses 



632 



I/- 618 
r 613 



RAM 



Interface 



T 



619 



item ID-* sub-item ID 



1 



670 
672 



sub-request ID ->(Hem ID; sub-Item ID) 



sup-responses 



632 



630 



sup-response 



632 



FIG. 6 



SUBSTITUTE SHEET (RULE 26) 



WO 2005/022424 



PCT7EP2004/009348 



8/8 



Receive request 



—700 



Apply Rules to request 



Sync. Communication | 



sub-request j(0<j<J) 



Async. Communication 



-704 



-702 



sub-request J (0< j<J): store IDs 
of sub-requests in DB 




-708 



I 



-706 



send sub-requests to partner 
systems 







receive sub-response j from 
partner system 




r 


j+1 


i 


r 


Generate Response from 
sub-responses 







receive sub-response from 
partner system 



-720 



722 



730 

I 



Store in 
DB 



712 



-714 




Read sub-responses from DB 



-716 



-726 



Generate Response from 
sub-responses 



-728 



Send Response 



-718 



FIG. 7 



SUBSTITUTE SHEET (RULE 26) 



